home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1483.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  6.2 KB  |  138 lines
  1. Responding to a few things by various people...
  2.  
  3. George Phillips <phillips@cs.ubc.ca> says:
  4. >Semantics: decode the "encoded-URL", grab it and execute it
  5. >with the rest of the URL.  I used the  "//" notation so
  6. >that executables can ouput "/" rooted URLs without having
  7. >to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
  8. >We can do the "encoded-URL" any way we like, but suppose that
  9. >: -> ; and / -> \.  A full exec: URL might look like:
  10. >
  11. >    exec://file;\bin\rn.html/comp/sources/misc
  12.  
  13. I'd be more inclined to encode the URL with the general percent escape
  14. notation, but that's just me.
  15.  
  16. (Unrelated question:  Consider the URL http://foo/search?bar%2Bbaz --
  17. how many search keywords does it have, and what are they?  My
  18. inclination is to interpret it as one keyword "bar+baz", though that's
  19. inconvenient for the server since it can't just do all the percent
  20. substitution immediately upon receiving the object.)
  21.  
  22. >However, with the MIME executable content type, I'd expect that
  23. >most exec: URLs would point to files, so file: would be the default.
  24. >Additionally, the browser might have some notion of a PATH for
  25. >exec: files (possibly as a first-level security mechanism), so the
  26. >whole thing could be shortened to:
  27. >
  28. >    exec://rn.html/comp/sources/misc
  29.  
  30. This sounds a bit more portable and a bit less anxiety-inducing as far
  31. as security is concerned.  A special directory (or set of aliases, or
  32. something) of safe commands described with somewhat abstract names
  33. could work out OK.  The result is that your local commands end up of
  34. the form:
  35.  
  36.     exec://mail-rfc822/x-mosaic@ncsa.uiuc.edu
  37.  
  38. or something like that.  Whether this is better than the form:
  39.  
  40.     mail-rfc822://x-mosaic@ncsa.uiuc.edu
  41.  
  42. (or something like that) is debatable either way; I think either is
  43. probably workable as long as the number of different things you can do
  44. that way is rather small, considered carefully, and centrally
  45. registered in some fashion.
  46.  
  47. Tony Sanders <sanders@bsdi.com> responds:
  48. >SAS strikes again (server aversion syndrome :-)
  49. >
  50. >    content-type: application/x-csh
  51.  
  52. No!  Anything but the Cshell!  Nobody move, or I post Tom Christiansen
  53. to the mailing list! :-)
  54.  
  55. >My reasoning:
  56. >  o Browsers cannot change on a whim, because for the Web to be truly
  57. >    useful to the user community at large all browsers must support the
  58. >    **same** set of features (to a large extent anyway).
  59. >  o Therefore we **must** have a definition for the browser that is simple
  60. >    and complete such that any features you might ever want can be done
  61. >    in a server.
  62.  
  63. I agree here, which is why I'm hesitant to extend things to a general
  64. execution type since programs (particularly, say, cshell programs) are
  65. inherintly non-portable.  I suppose we could try to agree on a
  66. language to specify programs to be executed in.  Such a language would
  67. need a number of attributes:
  68.  
  69. - Highly portable, will run on UNIX boxes, DOS boxes, Macs, whatever
  70. - Freely available
  71. - Can work in a "paranoid" fashion whereby it is reasonably safe to
  72.   execute untrusted code with it
  73.  
  74. I'm not sure such a language can even exist.  (Perl meets the first
  75. two criteria, at least.)  I'm pretty sure that inventing it is more
  76. than we can or should try to do.
  77.  
  78. >I'm not a purist or anything, I think it's fine if we want the browser to
  79. >support things like gopher and ftp directly but at some point we are going
  80. >to have to draw the line if we want most browsers to support a common
  81. >set of features (even <IMG> is a good example of this problem).
  82.  
  83. I concur; one problem is that most people will generally use just one
  84. browser and thus they'll write documents assuming that everyone else
  85. uses it too.  I've seen documents that rely on IMG too much, given the
  86. number of browsers that don't support it.
  87.  
  88. George Phillips <phillips@cs.ubc.ca> answers:
  89. >Servers are not _that_ easy to write.  They are if you're running UNIX
  90. >and you have either inetd.conf privileges or know how to do sockets.
  91. >Who knows what you'd have to do under VMS or MVS and you just can't
  92. >do them under MS-DOS.  On the other hand, writing a program which
  93. >dumps some HTML to a file is easy and possible under all systems.
  94. >It's very similar to adding to a server, but anybody, not just the
  95. >server administrator can do it and they can share with other non-privileged
  96. >users.
  97.  
  98. Servers _can be_ easy to write.  A base server could allow you to
  99. easily add new functionality of the variety you discuss without
  100. needing to understand the details of UNIX sockets (not that they're
  101. really that complicated anyway.)  Plexus, for example, allows this.
  102. Don't confuse limitations of particular implementations with
  103. limitations of HTTP servers in general.
  104.  
  105. >Even if you can easily run a server, you've got some security problems
  106. >to deal with.  Having a browser that will execute code (or URLs, whatever)
  107. >from documents is a little scary; having a server that anyone can
  108. >connect to execute code is really scary.  With the browser executing
  109. >code you leverage off the normal system authentication.  With a server,
  110. >you have to re-invent that.  Sure, these features are coming and
  111. >that's good; but you're building up an awful lot of stuff to solve
  112. >a simple problem.
  113.  
  114. Servers can run without privilige; ours runs as id "daemon" and
  115. doesn't have the priv to do much other than dequeue other people's
  116. print jobs.  Surely webmasters don't run their HTTP server as root?
  117.  
  118. Browsers, on the other hand, have to run as users and are thus capable
  119. of harming their users; I find using "normal system authentication"
  120. (as it exists on most machines) to run code in this kind of situation
  121. highly undesirable.
  122.  
  123. >Well, if you want to add features you have a choice.  Either make it
  124. >harder for the browser writers or make it harder for the server writers.
  125. >I maintain that the exec: URL scheme makes it a little harder for
  126. >the browser writers but is a boon for server writers since it truly
  127. >makes it easy to write a server (just like the simple inetd scripts,
  128. >but you don't need privilege).
  129.  
  130. Except that what has been written isn't a server at all, it's just a
  131. program.  It doens't provide a service to anyone except the person (or
  132. small group of people) who have examined it, decided it safe, and
  133. placed it on their list of commands for which exec:ing is permissible.
  134. (unless this procedure is not used, in which case it's a security hole
  135. you could drive an aircraft carrier through.)
  136.  
  137. - Marc
  138.